%
%~~
%~~  Projeto e Implementação
%~~
%
\chapter{Projeto e Implementação}
\label{05:chp:projetoimplementacao}

Este capítulo detalha os principais aspectos do projeto e de sua implementação. A seguir são apresentadas as principais tecnologias escolhidas para serem utilizadas na implementação do sistema, seguido de aspectos arquiteturais do sistema e de seu banco de conhecimento. Logo depois se tem a especificação e o detalhamento do funcionamento interno do sistema e, por fim, descreve-se a aplicação da técnica de mineração de dados escolhida e a integração de seus resultados com o sistema.

\section{Principais Tecnologias Utilizadas}
\label{01:sec:principaistecnologias}

Para o desenvolvimento do sistema especialista de apoio ao diagnóstico médico foi escolhida a linguagem Java, por ser uma linguagem de alto nível, orientada a objetos e que permite um alto grau de abstração e flexibilidade, o que possibilita rapidez na programação e soluções bem elaboradas. Além disso, para a programação, foram escolhidos três \textit{frameworks} em linguagem Java que aumentaram muito mais a agilidade de desenvolvimento. Estes frameworks são: Hibernate, Spring e SpringMVC.

O \textit{framework} Hibernate é responsável pela interface do sistema com o banco de dados, de maneira que facilita o mapeamento e sincronização entre os objetos instanciados durante a execução do sistema, com as instâncias correspondentes gravadas no banco de dados. O \textit{framework} Spring oferece uma ampla variedade de funcionalidades, mas no caso particular do sistema especialista ele é interessante pela sua capacidade de injeção de dependências nas entidades do sistema, tornando a programação das mesmas mais simples e intuitiva. O SpringMVC foi escolhido para a criação da interface do sistema com o usuário e pela facilidade de integração do mesmo com o \textit{framework} Spring. Utilizou-se, portanto, uma interface web como interface do sistema, devido à simplicidade oferecida pela tecnologia HTML.

Outras tecnologias utilizadas foram o banco de dados MySQL e o servidor web Apache Tomcat. O MySQL foi escolhido por ser um banco de dados relacional e de licença gratuita. O banco foi utilizado para a gravação dos dados da base de conhecimento e dos dados específicos de diagnósticos e de temperatura climática.  O servidor Apache Tomcat foi escolhido por ser um servidor voltado para a execução de sistemas web feitos em linguagem Java, e também por ser de licença gratuita e ideal para aplicações de pequeno porte, como é o caso do sistema especialista desenvolvido.

\section{Arquitetura do Sistema de Diagnóstico Médico}
\label{02:sec:arquiteturasistema}

A arquitetura do sistema desenvolvido está fundamentalmente baseada na arquitetura básica exposta na Seção~\ref{01:sec:sistemaespecialista}, possuindo ainda algumas diferenças relativas à extensão do sistema. Abstraindo a arquitetura básica para o paradigma orientado a objetos, podem-se identificar três entidades básicas, sendo estas: doença, sintoma e fator relevante.

A entidade doença foi modelada para conter todas as informações primordiais das doenças respiratórias abrangidas pelo sistema, as quais são: título da doença, descrição da doença e código CID (Classificação Internacional de Doenças). A entidade sintoma guarda informações referentes a manifestações de uma doença; sendo assim uma doença é composta de um ou mais sintomas. Fator relevante é uma entidade cujo objetivo é armazenar informações relacionadas à ocorrência ou causa da doença, podendo ser estas: idade, sexo, data mais comum de ocorrência e temperatura climática que mais influencia. Da mesma forma que sintoma, uma doença possui vários fatores relevantes.

A Figura~\ref{img:classes} expõe o diagrama de classes utilizado para o desenvolvimento do sistema. Observa-se que para as três entidades citadas utilizaram-se os nomes \textbf{DescricaoDoenca} para doença, \textbf{Sintoma} para sintoma e \textbf{FatorRelevante} para fator relevante. O nome escolhido para a entidade doença (\textbf{DescricaoDoenca}) deve-se a função descritiva da entidade no sistema.
\pagebreak
\begin{figure}[htb]
	\center
	\includegraphics[scale=0.9]{images/diagrama-de-classes.png}
	\caption{Diagrama de classes do sistema especialista.}
	\label{img:classes}
\end{figure}

Na Figura~\ref{img:classes} ainda pode-se observar a existência de duas classes abstratas denominadas \textbf{AtributoGenerico}, estendida pelas classes \textbf{AtributoFatorRelevante} e \textbf{AtributoSintoma}, e \textbf{ValorGenerico} que é estendida pelas classes  \textbf{ValorFatorRelevante} e \textbf{ValorSintoma}. Essas classes têm a função de descrever os sintomas e os fatores relevantes e foram assim concebidas pois existe a possibilidade de repetição de sintomas e fatores relevantes em diferentes descrições de doenças. Assim podem-se reutilizar atributos e valores em diferentes sintomas e fatores relevantes de doenças singulares (para entender melhor o conceito de atributo e valor veja o exemplo na Seção~\ref{01:sec:sistemaespecialista}).

Além dos atributos especificados no diagrama de classes, foi acrescentado nos sintomas, fatores relevantes e nas descrições de doenças um atributo do tipo enumeração denominado \textbf{ProbabilidadeSimbolica}. O objetivo desse atributo é especificar, de maneira estimada e não numérica, a probabilidade de ocorrência da entidade em que está presente. Esse atributo possui cinco valores possíveis sendo estes \textbf{alta}, \textbf{média}, \textbf{baixa}, \textbf{nunca} e \textbf{sempre}. A importância desse atributo no sistema está ligada a execução do mesmo e, portanto, será detalhado melhor na Seção 5.5.

\section{Modelagem do Mecanismo de Mineração de Dados}
\label{03:sec:arquiteturamineracao}

A modelagem que corresponde à implementação da mineração dos dados de ocorrências é extremamente simples, composta basicamente de cinco classes como indica o diagrama da Figura~\ref{img:classesmineracao}. Em \textbf{LimitesOcorrencias} ocorre a representação das regras de relacionamento geradas enquanto os dados são representados pela ocorrência. 

\begin{figure}[htb]
	\center
	\includegraphics[scale=0.7]{images/classesmineracao.png}
	\caption{Classes compondo a arquitetura do mecanismo de mineração}
	\label{img:classesmineracao}
\end{figure}


\section{Modelagem da Base de Conhecimento}
\label{04:sec:arquiteturabase}

A modelagem da base de conhecimento baseou-se em primeiro lugar na estrutura das entidades definidas na arquitetura do sistema e em segundo lugar na ordenação dos dados dentro da base de conhecimento. Conforme se observa no diagrama modelo entidade relacional da Figura~\ref{img:mer}, temos a tabela \textbf{descricaodoenca} para o armazenamento das descrições de doenças abrangidas pelo sistema, a tabela \textbf{sintoma} para o armazenamento dos sintomas das doenças e, de maneira similar, a tabela \textbf{fatorrelevante} para os fatores relevantes. A cardinalidade de relacionamento entre as tabelas se dá pelas suas chaves primárias de identificação e segue o mesmo padrão estabelecido para as classes do sistema.
\pagebreak
\begin{figure}[htb]
	\center
	\includegraphics[scale=0.9]{images/diagrama-mer.png}
	\caption{Diagrama modelo entidade relacional da base de conhecimento.}
	\label{img:mer}
\end{figure}

Na Figura~\ref{img:mer} também podemos observar a existência das tabelas \textbf{atributo}, \textbf{valor} e \textbf{atributovalor}. A tabela \textbf{atributo} armazena tanto os atributos de sintomas quanto os atributos de fatores relevantes e diferencia estes através do campo \textbf{tipo} que armazena \textquotedblleft FR\textquotedblright para fatores relevantes e \textquotedblleft SI\textquotedblright para sintomas. Da mesma forma, acontece para a tabela \textbf{valor} que pode armazenar tanto valores de sintomas quanto de fatores relevantes. A tabela \textbf{atributovalor} serve para estabelecer uma relação de \textquotedblleft muitos para muitos\textquotedblright entre os atributos e valores. Esta relação permite que um atributo esteja associado a muitos valores e, da mesma forma, um mesmo valor a muitos atributos. Através desta tabela é possível, em tempo de execução do sistema, recuperar para um determinado atributo quais são todos os seus valores possíveis.

Com relação à ordenação dos dados na base de conhecimento, preocupou-se com o fato de que a disposição destes afetaria diretamente a ordem de execução do sistema (maiores detalhes na descrição de funcionamento do sistema mais adiante). Procurou-se, então, organizar os dados de maneira que se garantisse uma influência positiva dos mesmos no sistema. A ordenação diz respeito às doenças e aos sintomas das doenças, e foi feita da seguinte forma: as doenças foram armazenadas em ordem alfabética de título; os sintomas foram armazenados segundo o número decrescente de ocorrência de seus atributos entre as doenças abrangidas pelo sistema. Desta maneira, os sintomas com maior chance de ocorrência foram armazenados antes, enquanto os sintomas com menor chance de ocorrência foram armazenados por último.

\section{Funcionamento do Sistema}
\label{05:sec:funcionamento}

O funcionamento do sistema pode ser descrito simplificadamente como um ciclo de questões, as quais devem ser respondidas pelo usuário. A cada questão respondida o sistema realiza a construção de uma hipótese que deve ser confirmada ou reformulada dependendo da resposta da próxima questão a ser feita para o usuário. O sistema termina quando não existem mais questões a serem realizadas, mostrando então a última hipótese como resultado final. Devido à natureza cíclica do sistema, pode-se denominar esse processamento como um ciclo de testes de hipóteses.

O ciclo é iniciado com a passagem de um primeiro sintoma. A partir deste, o mecanismo de inferência é capaz de inicializar todas as estruturas de dados de controle das quais depende, as quais são o conjunto de sintomas (MANIFS), o conjunto escopo de todas as doenças que possuem os sintomas informados (SCOPE) e o foco do diagnóstico (FOCUS) que é o elemento principal do mecanismo de inferência, pois guarda os possíveis diagnósticos inferidos até o momento (veja a seção~\ref{02:sec:mecanismohipotese}). O próximo passo é gerar uma nova questão sobre outro sintoma ainda não informado pelo usuário.

Nessa etapa existe a influência da ordem dos dados na base de conhecimento, pois o sistema buscará o próximo sintoma com maior número de ocorrências nas doenças presentes no escopo. A razão disso é que, priorizando questões sobre os sintomas com maior probabilidade de ocorrência, pode-se influenciar o mecanismo de inferência para trabalhar com o maior número de doenças possíveis no início do ciclo, garantindo um refinamento mais apurado no final. Além disso, as questões sobre sintomas mais comuns são propensas a possuírem respostas relevantes que aumentem a velocidade do mecanismo de inferência, enquanto que sintomas menos comuns não oferecem grandes vantagens na reformulação de hipóteses.

O processamento do sistema está basicamente concentrado em três estruturas principais: a interface com o usuário (\textit{View}), a controlador responsável por processar os dados enviados pela \textit{view} (CicloHipoteseController) e uma estrutura de serviço responsável por conter toda a lógica do mecanismo de inferência (MecanismoInferenciaService). As três estruturas possuem apenas uma instância durante todo o tempo de vida de execução do sistema. O diagrama de sequência da Figura~\ref{img:diagramasequencia} ilustra o processamento do sistema.

\begin{figure}[htb]
	\center
	\includegraphics[scale=0.7]{images/diagrama-de-sequencia.png}
	\caption{Diagrama de sequencia do sistema.}
	\label{img:diagramasequencia}
\end{figure}

Quando não há mais possibilidade de construções de questões sobre os sintomas, o sistema inicia as questões sobre os fatores relevantes que podem influenciar a aquisição de doenças. Estes estão relacionados com o conhecimento obtido a partir da mineração do banco de diagnóstico e de temperaturas climáticas. Uma vez respondidas todas as questões sobre fatores relevantes, o sistema inicia a etapa de ordenação das doenças presentes no foco segundo as suas probabilidades de ocorrência. Essa ordenação é feita com base nas probabilidades simbólicas relacionadas com cada doença, de maneira que as doenças com maior probabilidade de ocorrência são as primeiras indicadas no diagnóstico final.

Da maneira como foi projetado o sistema pode lidar com um grande número de doenças respiratórias. No entanto, na prática, com um conjunto de apenas 15 doenças que apareciam no banco de diagnósticos, raramente encontra-se mais que uma doença no diagnóstico final. Para testes mais amplos do sistema deve-se buscar o enriquecimento da sua base de conhecimento com um conjunto maior de  doenças.

Com o diagnóstico da doença definido, é possível utilizar o código CID da doença como entrada para o mecanismo de inferência. Este mecanismo investiga o relacionamento entre as ocorrências da doença e as do mês em que ocorreram traçando um esboço do quanto a temperatura pode ter influenciado aquela ocorrência. O mecanismo funciona da seguinte forma: o sistema automaticamente passa o código de cada doença diagnosticada para as funções de mineração, que levanta as temperaturas médias do estado de São Paulo e as respectivas ocorrências daquela doença na mesma região.

Após, o mecanismo classifica as temperaturas maiores que 24 graus celsius como \textquotedblright alta\textquotedblright, entre 18 e 24 graus como \textquotedblright média\textquotedblright e qualquer valor abaixo de 18 como \textquotedblright baixa\textquotedblright. Isto facilita a representação da informação pois para o ser humano valores como 26 ou 28 graus possuem menos valor do que saber em que faixa de temperaturas aquele mês se caracterizou. Estas faixas serão referenciadas como classes nesta breve explicação.

Similarmente, o mecanismo divide as ocorrências da doença em faixas onde alguma classe de temperatura (alta, média ou baixa) predominam, com um erro mínimo. Este erro mínimo é a quantidade de classes de temperatura que estão em uma faixa de ocorrências mas que não são as predominantes. Exemplificando: uma faixa de ocorrências entre 1200 e 1600 pode ter a predominância de temperatura de 15 ocorrências da classe \textquotedblright baixa\textquotedblright, mas existirem 2 ocorrências médias ainda dentro desta faixa. Este erro mínimo, no exemplo 2, é definido arbitrariamente, e sua função é impedir um problema conhecido como \textit{overfitting}, que simplificadamente visa limitar a quantidade de regras produzidas.

Este processo é realizado em um conjunto limitado em 90\% dos dados disponíveis, de cerca de 60 meses. Os outros 10\% são utilizados para testar se a taxa de erro das faixas definidas está dentro de um valor adequado. Isto faz parte de um processo de escolha de grupos de treinamento e teste definido por \citet{Witten05} como \textit{ten-fold} onde um grupo que apresenta erro reduzido será escolhido para representar o modelo.